I see this a lot. Did this method get changed to be Optional? Why?

The ProtocolGenerator context is kind of a bit of a grab bag currently, in some instances a writer is to be expected, in other instances the delegator that is stored on the context is used and no writer is expected. This was just to make that contact a bit clearer that it may not be there.

This was just something that I noticed when I was refactoring context to make it immutable after construction.

Do these kinds of interfaces generally have godocs?

Yes, next revision will include documentation, just wanted to get this out for initial feedback on the overall implementation.

Is this here to prevent zero values from being serialized? If so, I don't think that's the correct behavior for document types. They're meant to carry whatever input they were given, so I expect if someone populates a 0 or [] or whatever, then it's serialized.

This is here to detect if a value is a zero-value, this doesn't prevent serialization of the zero value unless the user instructed the document marshaler via a struct tag likedocument:",omitempty", where omitempty indicates that zero-values should not be serialized.

Does this class need to be public?

Yes, these exported constants are needed so that protocol implementation parts make symbol references to the types.

Can you give more info on what this generates? Do you generate a document type per type defined in the model? Do you generate a single document type used by every document type, and this mostly just generates the serde code specific to the protocol?

To add onto this, it would be generally nice to have example usage.

Will add some clarifying code examples sections to this class documentation. To summarize what is being created here: Each service client generates its own document type interface definition. This ensures that document types that are sent or received from the service are bound to the client package and it's associated client protocol. This prevents the situation where a user receives a set of protocol document bytes in service client A and tries to round-trip it by plugging it directly into service client B (which may be a different protocol and where the raw captured bytes can't be used). User who want to plug a document from service client A into client B would need to first unmarshal the document into a Go type, and then pass that Go type to the NewLazyDcoument constructor in the service client B package.

To add onto this, it would be generally nice to have example usage.